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

Re: What determines a Product?

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Fri, 14 Oct 2011 10:26:59 +0200
Cc: Chacha Slayton <charlene.c.slayton@gmail.com>, Dan Brickley <danbri@danbri.org>, public-vocabs@w3.org
Message-Id: <F59B1804-B961-4D9D-A685-7D73C725FC55@ebusiness-unibw.org>
To: Pravir Gupta <pravir@google.com>
Hi Pravir,

> Chacha,
>  you can model this with schema.org as Product which has multiple Offers. So the product will have one image, description, etc. and then each Offer will have price, etc.
> Example page that has this markup - http://www.ebay.com/ctg/Logitech-Revue-/97019743


yes, but if you have multiple product variants with individual features or identifier (e.g. a varying GTIN/UPC/EAN for each), then you cannot link from the base model to the variants without

> http://purl.org/goodrelations/v1#isVariantOf

If you want to keep the information that the variants are derived from a base model, then I would 

- create one additional http:/schema.org/Product with the basic features
- create one http:/schema.org/Product  for each variant
- link each of the latter to the base model with 
> http://purl.org/goodrelations/v1#isVariantOf
- create one http://schema.org/Offer for each variant

This is what Volkswagen is using heavily in their structured data for cars, see

  http://purl.org/coo/ns

Martin

On Oct 14, 2011, at 1:48 AM, Pravir Gupta wrote:

> Chacha,
>  you can model this with schema.org as Product which has multiple Offers. So the product will have one image, description, etc. and then each Offer will have price, etc.
> Example page that has this markup - http://www.ebay.com/ctg/Logitech-Revue-/97019743
> 
> -Pravir
> 
> On Thu, Oct 13, 2011 at 9:52 AM, Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote:
> Hi Chacha:
> 
> GoodRelations has a property
>   http://purl.org/goodrelations/v1#isVariantOf
> that can be used to model many variants for a single base product with ease.
> 
> It should be possible to use this with schema.org in combination as of now.
> 
> Martin
> 
> On Oct 13, 2011, at 6:25 PM, Chacha Slayton wrote:
> 
> > Hi Dan,
> >
> > Here are some real world examples, where products have unique part numbers (UPC codes) but all share the same product description.
> >
> > http://www.go2marine.com/product.do?no=93408F
> >
> > http://www.go2marine.com/product.do?no=155840F
> >
> > Charlene
> >
> >
> >
> > 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 UPC
> > > 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 Friday, 14 October 2011 08:27:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:56 GMT