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.