Documentation/Product features

= Product Features =

Overview
Originally, GoodRelations was designed to be used in combination with an additional ontology for product types and their properties, like


 * eClassOWL,
 * The Vehicle Sales Ontology,
 * The Tickets Ontology, or
 * The Accommodation Ontology (for a full list, see this this page}.

Those vocabularies provide very precise terms for modeling product types and their features based on specializations of
 * gr:QuantitativeValue,
 * gr:QualitativeValue,
 * gr:qualitativeProductOrServiceProperty,
 * gr:quantitativeProductOrServiceProperty, and
 * gr:datatypeProductOrServiceProperty.

This pattern is ideal for consuming e-commerce data, since one can easily harmonize different units of measurement or define mappings between product features. However, it turned out that for publishing product features from shop sites and manufacturer data sheets, it is often too much of a burden to map the available product data into a standardized products or services ontology and its types and properties.

Also, when using the 300,000 types from http://www.productontology.org, there are often no adequate product property definitions available.

Hence, GoodRelations from release 2012-08-01 onwards supports a novel pattern based on that allows publishing arbitrary property-value pairs for product features.
 * gr:ProductFeature and
 * gr:Feature

With that feature, a shop owner could easily mark-up product feature tables and preserve as much data and as much data structure and other meta-data as possible without the need to cleanse and lift the data before publishing it. That will be left to the consuming client.

A consumer of GoodRelations data should try to lift instances of gr:ProductFeature and gr:Feature to the original, richer structures of GoodRelations.

This new pattern follows the GoodRelations design principles of
 * Dynamic Data Granularity,
 * Lexical Carry-Over,
 * Incremental Refinement, and
 * Deferred Consensus.

Publishing Property-Value Pairs with gr:ProductFeature and gr:feature
Assume we have the following information


 * Product name: ACME Electric Anvil
 * Features:
 * Power supply: 110-220 Volts
 * Weight: 2.25 lb.
 * Safety belt: yes

This could be modeled as follows:

Microdata Syntax in the schema.org Namespace
If we know the proper UN/CEFACT Unit Codes for the units of measurement, like
 * VLT for volt and
 * KGM for kilogram,

then we should use the unitCode property of schema.org (or the gr:hasUnitOfMeasurement property when in the GoodRelations namespace) instead of unitText:

Turtle Syntax in the schema.org Namespace
In Turtle syntax (e.g. as a result from crawling and parsing), this will look as follows:

Lifting gr:ProductFeature for Consumption
We have seen that the gr:ProductFeature / gr:feature combo simplifies the publication of product features. However, the resulting data will not match against queries for the main GoodRelations meta-model. Hence, a client that crawls Web data, in particular RDFa and microdata markup, should try to lift and augment respective property-value pairs.

For instance, we could try to find a matching product feature in a GoodRelations compatible products ontology. For weight, we may use schema:weight directly. For power supply, we assume foo:operating_voltage and for safety belt, we assume foo:belt for the sake of this example.

The target data would then look as follows: