Documentation/Product or Service

= Product or Service =

Notes for Schema.org
When applying this pattern in the schema.org namespace, please note the following naming differences:


 * 1) schema:IndividualProduct = gr:Individual
 * 2) schema:ProductModel = gr:ProductOrServiceModel
 * 3) schema:Product = gr:ProductOrService
 * 4) schema:SomeProducts = gr:SomeItems

When combining the three more specific product types with one of the subtypes of http://schema.org/Product, like http://schema.org/Car, you have to use a multi-typed entity, like so:

Overview
GoodRelations disambiguates the broad notion of a product into three different types of entities:

1. A real product, like my laptop, my car with this VIN and mileage, a particular item on an eBay auction. The important thing is that all information said about that product relates to the same entity.

The respective GoodRelations class is gr:Individual.

Examples are the items on eBay auction pages or used cars.

2. A product model, i.e. a datasheet, like "Nikon T90", "iPod Nano 16 GB", or similar. This is basically the abstract definition of product features for mass-produced commodities. The nice thing is that if you are able to spot the link from a product to its product model, you can enrich the often shallow product description (e.g. from a shop page) with the rich feature data from the model page on the manufacturer's site.

In theory, there are at least two ways of modeling product models:
 * as abstract entities, e.g. subtypes of foaf:Document etc.
 * as prototypes, i.e. a special form of products.

GoodRelations treats product models as prototypes, since this allows using the same types (TV set, car, ...) and the same properties (weight, voltage,...) for products and product models alike, even though they mean different things for products vs. datasheets. (The weight of 5 kg for a TV set means that the TV set weighs 5 kg. The weight of 5 kg for a datasheet of a TV set means that each TV set of that make and model will, by default, weigh 5 kg.)

The respective GoodRelations class is gr:ProductOrServiceModel.

Examples are the product pages on manufacturers' sites, like Sony, Nikon, Volkswagen - the entities references are not products, but their blueprints.

3. Then we have a third case, in which the entities exposed on the Web are neither products nor product models, but instead "black boxes" of products, which themselves do not have a public identity. For example, an Amazon page for a new book does not expose publicly individual book copies, but just states that they have multiple ones on stock.

The main semantic difference is that multiple statements about the same entity do not imply that the statements refer to the same individual product. For instance, if you say that you bought that entity and that someone else bought it, too, it implies that you own books from the same bag of books, but not the same copy. (The identity criterion is different.)

The respective GoodRelations class is gr:SomeItems.

These three subtypes are powerful, but it is of course also allowed to use the common abstraction gr:ProductOrService.

Examples: Modeling Products and Product Models
Now, modeling respective data using GoodRelations works by combining two classes per each product,
 * one class for the type of product, e.g. http://schema.org/Book for books, and
 * one class for distinguishing individual products (gr:Individual), product models (gr:ProductOrServiceModel), and bags of anonymous products (gr:SomeItems).

A Single Book Copy

A Book Title

Some Books