Axioms

= Useful Rules, Axioms, and Mappings for GoodRelations =

On this page, we are collecting optional rules and axioms and linksets for GoodRelations that are not part of the formal ontology specification but can be helpful in many cases.

They can be imported in your model when they don't hurt. Some have side-effects that are unwanted in some scenarios.

Such rules are not part of the core GoodRelations ontology for two reasons:


 * For semantic aligments with   other vocabularies ("ontology mappings"), the problem is that the candidate vocabularies are often defined in different ontology languages or language fragments, e.g. RDF-S, OWL DL, and OWL Full. Including such alignments in GoodRelations directly will turn GoodRelations into OWL Full, which is something we want to avoid as much as we can. The reason is that there are applications for GoodRelations both
 * in the "open, wild Web", where OWL Full will anyway be the likely language fragment, and incomplete, lightweight reasoning be sufficient, and
 * in controlled, corporate settings, where staying within OWL DL is an important feature for consistent DL reasoning. Also, those alignments that are useful in practice are often broader than correct. While they are good in 90% of the cases, they will have unwanted side-effects in 10% of the cases. Thus, including them must be optional
 * For additional rules and axioms, the problem is that they raise the bar for computing the full entailment, which may slow down reasoner performance. Also, they are very promising topics for further research and fine-tuning, so the examples given in here will be initial sketches only. Practitioners will be able to improve them a lot in terms of computational efficiency and quality. If you are working on business applications that consume GoodRelations data, this is what you should dedicate resources to.

Recommended Default Rules
The following rules should be used by default for any GoodRelations data. They require just a simple rule reasoner.

Product Models
In GoodRelations, you can link a product or service (both gr:Individual (former gr:ActualProductOrServiceInstance) and gr:SomeItems (former gr:ProductOrServicesSomeInstancesPlaceholder)) to a make and model (gr:ProductOrServiceModel), i.e. the "datasheet" that specifies technical features for all those individual objects.

Now, our intuition tells us that an actual product inherits all technical features from its make and model, unless specified at for that particular individual specifically.

Example: ''If the Nikon camera model T80 has a weight of 400 g, then a camera instance of which is known that it is of this make and model can be inferred to weight 400 g, too. ''

SPARQL CONSTRUCT Rule: Possible extensions: Additional rules for gr:isConsumableFor, gr:isSimilarTo, and gr:isAccessoryOrSparePartFor.

(Previous page: Ruleset for Product Model Properties, now redirects to this section.)

Expand gr:includes
The gr:includes property is a shortcut for the many cases in which the product includes just one item. By that you spare the effort for an additional gr:TypeAndQuantityNode or even the gr: SomeItems node. However, when querying, you should search for the full pattern, or both. In order to expand all usages of gr:includes to the full pattern, activate the following TWO (!) SPARQL CONSTRUCT rules

Note: In the 2010-09-16 service update of GoodRelations, the usage of gr:includes is being expanded to links between gr:Offering and gr:ProductOrServiceModels, which can drastically reduce the markup effort.

SPARQL CONSTRUCT Rule #1: SPARQL CONSTRUCT Rule #2:

Product Variants
The gr:isVariantOf object property allows for modeling product model variants. This states that a particular ProductOrServiceModel instance is a variant of another ProductOrServiceModel. It is pretty safe to infer that the variant inherits all gr:quantitativeProductOrServiceProperties, gr:qualitativeProductOrServiceProperties, and gr:datatypeProductOrServiceProperties that are defined for the first gr:ProductOrServiceModel, except for those defined for the variant individually.

Exception: gr:hasEAN_UCC-13 and gr:hasStockKeepingUnit should not be inferred for the variant.

Example: foo:Red_Ford_T_Model gr:isVariantOf foo:Ford_T_Model

Note 1: gr:isVariantOf is NOT a transitive property in GoodRelations, because the semantics of defaults is a bit more complicated. In particular, the order of reasoning steps matters. If A is a variant of B and C a variant of B, then B should first inherit properties from A and C from B, before C would inherit properties from A. Otherwise, properties defined at the level of B could be overwritten by properties defined at the level of A. This problem is relevant only if model data overwrites product features at intermediate levels AND if there is more than one level of variantOf relationships. A pragmatic solution is to execute the construct rule a few times sequentially.

Note 2: There is a problem with quantitative values held in blank nodes in the current rule, because such may not be properly replicated. Avoid blank nodes for quantitative values, if possible.

SPARQL CONSTRUCT Rule:

Data Cleansing: Entity Consolidation Etc.
The distributed character of the Web makes it very likely that the exact same entity is being defined in multiple graphs. In particular, there will be significant redundancy in the definition of - Business Entities and - Product Models. The main cause is that providers of data may define entities locally rather than searching for an authoritative URI on the Web. For example, someone exporting a catalog may want to refer to the manufacturer of a gr:ProductOrServiceModel or gr:SomeItems without searching for the authoritative URI of that manufacturer. This is not a major technical problem, since providers of commerce dataspaces will very likely offer entity consolidation as one important feature.

For your own projects, you can start with the following simple SPARQL CONSTRUCT rules to create owl:sameAs statements so that multiple definition of the very same entities will be treated as one.

Consolidate Product Models that have the exact same gr:hasEAN_UCC-13
On Openlink Virtuoso, you can use instead of which will be faster.

Note that the current rules assume perfect equivalence of the legal names resp. the EAN/UPC code. You could use more sophisticated filters for expanding the scope of the consolidation, e.g. ignoring capitalization and special characters (e.g. "Miller Ltd." vs. "miller ltd"). Important: 1. Make sure you consolidate only nodes of the same type. For example, two gr:Offerings may have the same gr:hasEAN_UCC-13 property, but are of course not the same. 2. For local sets of such statements, you have any degree of freedom and I encourage you to experiment with different ones. Before publishing such sameAs statements, however, run thorough quality checks first. Reckless usage of sameAs can spam the Web of Linked Data, and dataspaces will consequently ignore all your graphs.

Links to other Vocabularies: Safe
The following mapping rules are very much recommended and should practically have no unwanted side-effects, other than turning your data into OWL Full:

Links to FOAF, iCal, and other Vocabularies: Unsafe
The following schema mappings are often useful in practice. While they are good in 90% of the cases, they will have unwanted side-effects in 10% of the cases. Thus, including them must be optional. In particular, they may turn your model into OWL Full.

Acknowledgements: A big thanks to Andreas Harth (ahaATaifb.uni-karlsruhe.de) for several suggestions! Candidates:


 * Locations: maybe foaf:based_near and geo:Point
 * Yahoo / foaf: Match foaf:depiction and media:image