W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2011

Re: What determines a Product?

From: Chacha Slayton <charlene.c.slayton@gmail.com>
Date: Thu, 13 Oct 2011 09:25:18 -0700
Message-ID: <CAHa0bPfM5A_8NYtHu04uEzWy=0_HZU=VwEc_eiVMGar=G1QDJQ@mail.gmail.com>
To: Dan Brickley <danbri@danbri.org>
Cc: public-vocabs@w3.org, Pravir Gupta <pravir@google.com>
Hi Dan,

Here are some real world examples, where products have unique part numbers
(UPC codes) but all share the same product description.




On Tue, Oct 11, 2011 at 1:47 PM, Dan Brickley <danbri@danbri.org> wrote:

> On 11 October 2011 01:57, Chacha Slayton <charlene.c.slayton@gmail.com>
> wrote:
> > Hello,
> >
> > I think there is may be a conflict in the schema.org mark-up and the
> search
> > engine's requirements that could very likely produce duplicate content.
> This
> > may be an issue with other e-commerce web sites.
> >
> > It appears that the mark-up only supports a single product per page as
> > opposed to multiple products (product variations) as in the case of
> clothing
> > (ie. products with different sizes and colors, applications, but unique
> > codes or part numbers for each variant). Please let me know if there is
> > support for in these instances.
> As I understand the Schema.org vocabulary, and it's supporting
> notations (microdata and RDFa), you should be able to describe many
> different products within a single page. This is of course quite a
> separate issue from the question of which search engine products will
> actually understand each combination of terms.
> In the FAQ entry comparing Facebook's RDFa Open Graph markup with
> Schema.org, the answer does make clear this intent to describe things
> quite richly:
> http://schema.org/docs/faq.html#4
> """Q: How does schema.org relate to Facebook Open Graph?
> Facebook Open Graph serves its purpose well, but it doesn't provide
> the detailed information search engines need to improve the user
> experience. A single web page may have many components, and it may
> talk about more than one thing. If search engines understand the
> various components of a page, we can improve our presentation of the
> data. Even if you mark up your content using the Facebook Open Graph
> protocol, schema.org provides a mechanism for providing more detail
> about particular entities on the page.
> For example, a page about a band could include any or all of the following:
> A list of albums
> A price for each album
> A list of songs for each album, along with a link to hear samples of each
> song
> A list of upcoming shows
> Bios of the band members"""
> > In order to not produce duplicate content, we typically form a “family
> page”
> > with all the pertinent information (i.e. photo, product description) and
> the
> > variations as “children” listed below. Therefore, we have the following
> > information ALL on one page:
> [...]
> > Not to belabor the point, but here is another example, if you purchase a
> > sweater and there are multiple sizes, it doesn’t make any sense to have a
> > separate product description for each size when the only variation is the
> > size. However, each size has its own price, weight, upc code, stock
> level,
> > item no, etc.
> >
> > Obviously we could have separate pages with slightly different product
> > descriptions, but this would be a step backward for the customer who is
> used
> > to picking out a product and selecting the size, color, voltage or other
> > minor variations. How do we properly format the mark-up in our case? Do
> all
> > products (unique skus) need their own product descriptions and or URLs?
> > Maybe the big question here is -what determines a product?
> I can't answer that bigger question ("what determines a product"), but
> thank you for supplying a complete example. It could be useful to base
> some examples on this. Do you have any URLs of public sites with this
> kind of data, so we can make a full realistic example?
> Dan
> ps. copying Pravir who might have thoughts on specifics re Google rich
> snippets
Received on Thursday, 13 October 2011 16:25:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:21 UTC